Parse, don’t validate

1つのエッセイの中で、いくつかのことを主張している

主張は分散させて別のノートに書く

要するに、

失敗しうるデータ構造を内部にまで入れない

境界部分で全て根絶させる

流れとしてはこんな感じ

プログラムの外部から内部に入る時に失敗し得ない型にすると良い

失敗し得ない型にすることで、内部ではhandlingが不要になり、実装がシンプルになる

値の正当性を確かめる時に、validationではなくparseしよう

ただ値チェックするだけのvalidationは漏れうるし、handlingも増える

parseし、仕様を満たしたデータ構造に変換すると良い

内部がシンプルになる

静的に漏れていないことを確認できる

後半は、Parse, don't validateの実践例

元々2つの課題があった

プログラム中でnull checkのようなhandlingが頻発するとダルい

仕様を満たしていることをチェックすることを強制したい

後者をやるためにはparseするしかない

どちらも境界部分でやればいい

このエッセイはなぜかvalidationを境界でやることをあまり前提していない

用語の注意

validate

値が正しいかどうかをチェックする

正しい場合は、voidを返す

正しくない場合はthrowする

code:例.hs

validateNonEmpty (_:_) = pure ()

validateNonEmpty [] = throwIO $ userError "list cannot be empty"

構造的でない外部の入力を、構造的なデータに変換する

正しい場合は、それを型に込めて値を返す

正しくない場合はthrowする

code:例.hs

parseNonEmpty (x:xs) = pure (x:|xs)

parseNonEmpty [] = throwIO $ userError "list cannot be empty"

validateには問題がある

チェック自体を強制できない

漏れる

チェックする関数を呼び忘れたことに気づけない

境界に置くことを強制できない

だから、プログラムの内部もで自由に実行できてしまう

すると、handlingがプログラム内に分散する

チェック済みであるという情報を伝達できない

parseの結果を信頼できるものにする

こうではなく

code:js

const data = parse(input); // dataはまだ信頼できない

if (validate(data)) {

const trusted = data;

}

これはアンチパターン

こうする

code:ts

try {

const trusted = parse(input); // 結果は信頼できる

} catch (error) {

throw new Error();

}

parseの結果が100%信頼できるようにする

関連

code:hs

getConfigurationDirectories = do

configDirsString <- getEnv "CONFIG_DIRS"

let configDirsList = split ',' configDirsString

when (null configDirsList) $

throwIO $ userError "CONFIG_DIRS cannot be empty"

pure configDirsList

これは最初想定していなかったerrorがthrowされることになるので問題

code:hs

main :: IO ()

main = do

configDirs <- getConfigurationDirectories

case head configDirs of

Just cacheDir -> initializeCache cacheDir

Nothing -> error "should never happen; already checked configDirs is non-empty"